Unbounded Color Engines

A Color Matching Method (CMM), also called a Color Engine, is a software component that does the color conversion calculations from one device's color space to another. This paper discuses a new working mode for CMMs that allows such software components to operate in a way that is not restricted by the gamut of the device encoding, the gamut of the profile connection space or any intermediate step. This allows ICC profiles to be used in new ways for a variety of applications. An open source CMM implementing this mode is also introduced. Background One of the main components of a color management system is the Color Matching Method, (CMM), which is the software engine in charge of controlling the color transformations that take place inside the system. By today, the vast majority of color management systems do use International Color Consortium (ICC) profiles. ICC color management is based on device characterization profiles. Color transformations can be obtained by linking those profiles. This can be done because ICC has defined a standard profile connection space, the ICC PCS, which can either be XYZ or CIE L*a*b*. Each ICC profile describes how to do the conversion between the device color space and the profile connection space. In the ICC paradigm, all the smarts of the color conversion are embedded into profiles, and the CMM just concatenates them with some minor adjustments. This is known as the “smart profiles, dumb CMM” approach. Figure 1. ICC color transforms as profile concatenation To implement the conversion device/PCS, ICC profiles can internally use three different math primitives: matrices, curves and multidimensional interpolation tables. Only certain combinations of those primitives are allowed, depending on the profile version and the direction being used. Up to the ICC specification 4.2, profiles had a limit on the precision they could deliver. The internal encoding of profiles did force them to have a precision of 8 or 16 bits at most. That limit on precision was a stopper in the adoption of ICC profiles by some applications, like RAW photo processing or digital cinema, where greater levels of accuracy are required. See figure 2 for a DPX real world example, where input values 0-40 map to same output value 2, and 16-bit integer encoding cause severe quantization in shadows. To overcome this limitation, in November 2006 the ICC approved the Floating Point Encoding Range addendum to the profile specification. With the introduction of floating-point data in the spec, ICC profiles are no longer limited to 8 or 16 bit, but to the broad range of 32-bit IEEE 754 floating point. That was a huge improvement when regarding precision and dynamic range, which is now only limited by floating point representation and can take as much as 10 Figure 2. KODAK VISION2 500T Color Negative Film 5218 / 7218 This addendum, however, introduced another improvement perhaps not so evident but equally important. Floating point encoding has a huge domain, which is nearly infinite, much larger than any real gamut. Based on that, one could think that a capable CMM using such kind of profiles could operate in an “unbounded mode” that would not have the limits that traditional CMMs have. Further investigation has demonstrated that it is certainly possible to write such CMM. And moreover, some old, very popular, ICC profiles can be successfully used in this unbounded mode as well, without any modification at all. Compatibility with existing profiles is a key feature to properly leverage a new feature. Many of the yet-existing images are encoded in popular color spaces like sRGB or AdobeRGB, and have those profiles embedded. A CMM capable to work in unbounded mode with such images and with such profiles would certainly be easier to adopt that any system requiring new profiles and new encodings for every single image. Bounds in ICC color management In ICC specifications previous to the Floating Point Encoding Range addendum, device encoding range must have definite bounds. According that, most, if not all, of today’s CMM perform some sort of clipping. To enumerate a few samples: Adobe ACE, Apple ColorSync and Windows ICM. Clipping happens because several reasons. One is the encoding of the device space. If we use a 8 or 16 bit representation of the color space, all encodeable values are inside device gamut by definition, and there is no way to represent out of gamut values. For example, in the traditional 8-bit encoding, device values goes from 0 to 255. This is encoded in one byte taking all available bits, and therefore there is no way to represent negative numbers or values over 255. 16 bit gives more precision but still clips values to be inside realizable gamut. Figure 3. RGB device encoding bounding More subtle clipping can happen inside the CMM without any evident trace to the end user, as another source of clipping in ICC color management is the encoding of profile connection space itself. Version 2 Lab PCS is based on an ideal reflection print that has white point mapped on perfect diffuser and black point mapped on perfect absorber. Real device range is then scaled to this hypothetical media which has infinite dynamic range. As a result, real device black point is mapped to Lab (0, 0, 0), and real device white point is mapped to Lab (100, 0, 0). The mapping of the measured colorimetry of the device white to (100, 0, 0) is accomplished using linear XYZ scaling. The media white point tag is then used to undo the scaling of the device white to produce "ICC-absolute" colorimetry values which are relative to the assumed adapted white. The reason to do this normalization is to maximize profile connectivity in perceptual and saturation rendering intents. In normal ICC operation mode, the device encoding bounding do not limit the dynamic range that can be supported because there are no restrictions on the relation between the device encoding minimum and black, or between the device encoding maximum and the assumed adapted white. But as a side effect of that mapping, values below black point are not encodeable; they result in negative L* or XYZ and most CMM clips them to zero. Highlights over white point may suffer same clipping, since the perceptual PCS does map device white point to Lab (100, 0, 0). Since this happens in the profile connection space, the end user does not see this effect directly but as an indirect result XYZ PCS has an encodeable range of [0...1.99997] which encompasses most of today gamuts, It is unlikely that any device values will have corresponding D50 chromatically adapted XYZ values above 1.99997. However, it is possible for this to occur in some unusual circumstances, for example in situations of extreme fluorescence where the media white is much darker than some saturated colors. The media white is defined to be the lightest neutral color that a capture device can capture, or an output device can produce. It is also possible that some device values may have corresponding XYZ values that are negative. Such values can result from digital camera color analysis matrices, or chromatic adaptation transforms applied to extremely saturated blue colors. In most cases, it is acceptable to clip negative XYZ values to zero as such values do not correspond to real colors. However in some cases this may be unacceptable, for example if perfect round tripping is desired Lab PCS is more limited. A device value of (0, 255, 0) in AdobeRGB, for example, results in Lab (83.2, -128.1, 86.1) which is not encodeable in Lab PCS. Lab PCS has a*/b* axis restricted to 128 127 in version 4 of the ICC spec. Version 2 of ICC spec have slightly different limits: 128 127.996) but again that’s not enough to hold entire AdobeRGB gamut. Bounding CMM example Let’s take an example to demonstrate the PCS clipping effect by using Adobe Photoshop CS4. If we setup Photoshop to use sRGB as working space, and convert by means of relative colorimetric intent a Lab value of: